The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by their inclusion in this section.
Different types of distributed computing architectures exist. One type is the client-server architecture. In a typical client-server architecture, tasks or workloads are distributed between the provider of a resource or a service, called a “server,” and the requester of the resource or service, called a “client.” In some configurations, the client and server communicate over a data network from different computing machines via a data networking protocol (e.g., TCP/IP, TCP/IP with SSL, etc.). However, the client and server may operate on the same machine and communicate with each other via a data networking protocol or other interprocess communication protocol (e.g., named pipes).
Often, the server is responsible for protecting the resource or service. That is, the server is responsible for ensuring that only authorized client requests successfully access the protected resource or service. A common way for the server to protect the resource or service is to require the client provide valid authentication credentials before allowing a request from the client to access the protected resource or service. The valid authentication credentials (e.g., valid username/password, valid digital certificate, etc.) may establish an identity associated with the client. The established identity may be used by the server for authorization. For example, the associated identity may identify a user of the client. Requests from the client to the server may be made in the context of the established identity. The server, then, can authorize a request from the client based on the established identity. For example, the server may authorize the request based on a role or roles the user has according to a role-based access control scheme.
However, the operator of the server may desire to authorize access to the protected resource or service based on more than just an established identity associated with the client. For example, the operator may want to authorize access based on one or more client security factors. In this description, a “client security factor” is information programmatically obtained at a client machine that is provided to a server for at least the purpose of the server authorizing requests from the client machine to access a protected resource or service based on the client security factor. One non-limiting example of a client security factor might be a security patch level of the client machine. The operator of the server may wish, for example, to prevent client machines that do not have the latest security patches installed from accessing the protected resource or service.
One challenge with authorizing client requests at a server based on client security factors is trust. In particular, the client machine may not be under control and management of the operator of the server. For example, the client machine may be an employee's or contractor's personal computer. As such, the operator of the server may not trust client security factors obtained by the client machine. For example, the operator of the server may worry that a security patch level reported by the client machine is inaccurate or falsified (e.g., spoofed). Without trust in client security factors obtained by the client machine, the server cannot reliably make authorization decisions based on the client security factors.
The present invention provides trusted client security factor-based authorizations at a server. The solution may be used in lieu of or in addition to other techniques for authorizing client requests to access a protected resource or service at a server.